Closes #4613. Test-only — no runtime change.

The gap, measured

#3770 (data path) and #3867 (analytics cube auto-inference) are both implemented and unit-tested. Neither implementation is what this protects. It protects the wiring, which nothing asserted.

Two deletion experiments, each removing only the lines that hand the probe to the service — implementation and unit tests untouched:

Experiment A means the #3867 gate could be deleted from production by one refactor and nothing in the repo would notice. It only logs a one-shot stand-down warn that nobody asserts, so /analytics/query silently reverts to "any table the connection can see is readable" — the exact state #3867 was filed for.

Why the asymmetry — it's the test shape, not luck

• 曝露 gate 对未知对象放行所依赖的「data path 会 404」并不成立 —— findData 无存在性校验(#3545 同类前提) #3770's suite drives the real protocol.findData. The call site is inside the object under test → deleting it reddens.
• analytics /query 未做 cube 存在性校验,未注册名直达驱动当表名;且错误路径原样回显驱动 SQL(#3770 同类,另一子系统) #3867's suite injects the probe as config: new AnalyticsService({ isRegisteredObject }). It proves how the service behaves once handed a probe — never that anyone hands it one.

Prime Directive #10's closing line in mirror image: a case label is not enforcement, check the CALL SITE. (#3106 was the same lesson pointing the other way.)

This repo has already paid for this exact gap once. From analytics-rls.dogfood.test.ts's own header, verbatim:

Every pre-existing analytics RLS test injects getReadScope as a fake into a hand-built AnalyticsService. NONE booted the real plugin, so the getReadScope → security.getReadFilter auto-bridge had zero coverage — which is how the gap shipped.

That was #3597. #3867 sits in the identical position, and the pattern is spreading — measure-source-field-gate.test.ts is a newer gate wired the same injected way.

Verified to bite

With this test in place, the same two experiments now redden:

Why sqlite_master and not an invented name

The harness boots sqlite-wasm, so sqlite_master is guaranteed to exist and hold rows while never being a registered object. That is the case that actually regressed — #3867's live repro read real rows out of it ({index: 262, table: 71, view: 1}) — and it keeps the gate honest: a 404 here cannot be explained away by "there was no table anyway", which is precisely the loophole the pre-#3770 driver-error-string 404 depended on.

What's asserted

Everything goes through bootStack (real plugin lifecycle, real Hono app, real HTTP) and never constructs a service by hand.

• Premise — the table IS readable straight through the engine. Ground truth, and it doubles as a pin on 曝露 gate 对未知对象放行所依赖的「data path 会 404」并不成立 —— findData 无存在性校验(#3545 同类前提) #3770's choice to gate at the protocol ingress rather than the engine, so internal callers (hooks, flows, migrations, raw ObjectQL) keep working.
• 曝露 gate 对未知对象放行所依赖的「data path 会 404」并不成立 —— findData 无存在性校验(#3545 同类前提) #3770 — GET /data/sqlite_master → 404 OBJECT_NOT_FOUND (SCREAMING_SNAKE per ADR-0112); the write verb too.
• analytics /query 未做 cube 存在性校验,未注册名直达驱动当表名;且错误路径原样回显驱动 SQL(#3770 同类,另一子系统) #3867 — POST /analytics/query scalar and grouped, plus /analytics/sql, all 404, with the response asserted not to carry "rows" or FROM "sqlite_master".
• Controls — a registered object still serves on /data, and still auto-infers a cube on /analytics/query (the object-metric KPI path analytics /query 未做 cube 存在性校验,未注册名直达驱动当表名;且错误路径原样回显驱动 SQL(#3770 同类,另一子系统) #3867 narrowed but must not have removed). Without these, a simply-broken boot would make every 404 above pass for the wrong reason.

pnpm test green across the monorepo (132/132 turbo tasks).

Empty changeset — the CI check explicitly allows one for changes that release nothing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EWHv5StvA4KDkHhx19xufX

Generated by Claude Code